브라우저 보안: 콘텐츠 보안 정책(CSP) 심층 분석

오늘날의 웹 환경에서는 보안이 무엇보다 중요합니다. 웹사이트는 크로스 사이트 스크립팅(XSS), 데이터 주입, 클릭재킹 등 잠재적인 공격의 끊임없는 공세에 직면해 있습니다. 이러한 위협에 대한 가장 효과적인 방어책 중 하나가 바로 콘텐츠 보안 정책(CSP)입니다. 이 글에서는 CSP에 대한 포괄적인 가이드를 제공하며, 웹 애플리케이션 보안을 위한 CSP의 이점, 구현 방법, 모범 사례를 살펴봅니다.

콘텐츠 보안 정책(CSP)이란 무엇인가?

콘텐츠 보안 정책(CSP)은 크로스 사이트 스크립팅(XSS) 및 데이터 주입 공격과 같은 특정 유형의 공격을 탐지하고 완화하는 데 도움이 되는 추가적인 보안 계층입니다. 이러한 공격은 데이터 탈취부터 사이트 변조, 멀웨어 배포에 이르기까지 모든 것에 사용됩니다.

CSP는 본질적으로 브라우저에 어떤 콘텐츠 소스를 안전하게 로드할 수 있는지 알려주는 허용 목록(whitelist)입니다. 엄격한 정책을 정의함으로써, 명시적으로 승인되지 않은 소스의 콘텐츠를 무시하도록 브라우저에 지시하여 많은 XSS 공격을 효과적으로 무력화합니다.

CSP는 왜 중요한가?

CSP는 다음과 같은 몇 가지 중요한 이점을 제공합니다:

• XSS 공격 완화: 브라우저가 콘텐츠를 로드할 수 있는 소스를 제어함으로써 CSP는 XSS 공격의 위험을 극적으로 줄입니다.
• 클릭재킹 취약점 감소: CSP는 웹사이트가 프레임으로 표시될 수 있는 방식을 제어하여 클릭재킹 공격을 방지하는 데 도움이 될 수 있습니다.
• HTTPS 강제: CSP는 모든 리소스가 HTTPS를 통해 로드되도록 보장하여 중간자 공격(man-in-the-middle attacks)을 방지할 수 있습니다.
• 신뢰할 수 없는 콘텐츠의 영향 감소: 신뢰할 수 없는 콘텐츠가 페이지에 어떻게든 주입되더라도 CSP는 유해한 스크립트가 실행되는 것을 막을 수 있습니다.
• 보고 기능 제공: CSP는 위반 사항을 보고하도록 구성할 수 있어 보안 정책을 모니터링하고 개선할 수 있습니다.

CSP 작동 방식

CSP는 웹 페이지에 HTTP 응답 헤더나 <meta> 태그를 추가하여 작동합니다. 이 헤더/태그는 브라우저가 리소스를 로드할 때 반드시 시행해야 하는 정책을 정의합니다. 이 정책은 일련의 지시어(directives)로 구성되며, 각 지시어는 특정 유형의 리소스(예: 스크립트, 스타일시트, 이미지, 글꼴)에 대해 허용된 소스를 지정합니다.

그러면 브라우저는 허용된 소스와 일치하지 않는 모든 리소스를 차단하여 이 정책을 시행합니다. 위반이 발생하면 브라우저는 선택적으로 지정된 URL에 이를 보고할 수 있습니다.

CSP 지시어: 종합적인 개요

CSP 지시어는 정책의 핵심으로, 다양한 유형의 리소스에 대해 허용된 소스를 정의합니다. 가장 일반적이고 필수적인 지시어에 대한 설명은 다음과 같습니다:

• default-src: 이 지시어는 다른 지시어에 의해 명시적으로 지정되지 않은 모든 리소스 유형의 기본 소스를 정의합니다. 기본적인 CSP 정책의 좋은 출발점입니다. `script-src`와 같은 더 구체적인 지시어가 정의되면 스크립트에 대한 `default-src` 지시어를 재정의합니다.
• script-src: 자바스크립트에 대해 허용된 소스를 지정합니다. XSS 공격을 방지하는 데 가장 중요한 지시어 중 하나입니다.
• style-src: CSS 스타일시트에 대해 허용된 소스를 지정합니다.
• img-src: 이미지에 대해 허용된 소스를 지정합니다.
• font-src: 글꼴에 대해 허용된 소스를 지정합니다.
• media-src: <audio>, <video>, <track> 요소에 대해 허용된 소스를 지정합니다.
• object-src: <object>, <embed>, <applet> 요소에 대해 허용된 소스를 지정합니다. 참고: 이러한 요소는 종종 보안 취약점의 원인이 되므로 가능하면 이 값을 'none'으로 설정하는 것이 좋습니다.
• frame-src: <iframe> 요소에 대해 허용된 소스를 지정합니다.
• connect-src: XMLHttpRequest, WebSocket, EventSource 연결에 대해 허용된 소스를 지정합니다. 이는 웹사이트가 데이터를 보낼 수 있는 위치를 제어하는 데 매우 중요합니다.
• base-uri: 문서의 허용된 기본 URL을 지정합니다.
• form-action: 폼이 제출될 수 있는 허용된 URL을 지정합니다.
• frame-ancestors: <frame>, <iframe>, <object> 또는 <applet>에서 현재 페이지를 포함할 수 있는 허용된 소스를 지정합니다. 이는 클릭재킹 공격을 방지하는 데 사용됩니다.
• upgrade-insecure-requests: 모든 비보안(HTTP) 요청을 보안(HTTPS) 요청으로 자동 업그레이드하도록 브라우저에 지시합니다. 이는 모든 데이터가 안전하게 전송되도록 보장하는 데 중요합니다.
• block-all-mixed-content: 페이지가 HTTPS를 통해 로드될 때 브라우저가 HTTP를 통해 어떤 리소스도 로드하지 못하게 합니다. 이는 upgrade-insecure-requests의 더 공격적인 버전입니다.
• report-uri: 브라우저가 위반 보고서를 보내야 하는 URL을 지정합니다. 이를 통해 CSP 정책을 모니터링하고 개선할 수 있습니다. *더 이상 사용되지 않으며, `report-to`로 대체됨*
• report-to: 브라우저가 위반 보고서를 보내야 하는 `Report-To` HTTP 헤더에 정의된 그룹 이름을 지정합니다. 이 지시어는 `Report-To` 헤더가 올바르게 구성되어야 합니다.
• require-trusted-types-for: DOM 기반 XSS 취약점을 방지하는 데 도움이 되는 DOM API인 Trusted Types를 활성화합니다. 특정 Trusted Types 구현 및 구성이 필요합니다.
• trusted-types: 싱크(sinks)를 생성할 수 있도록 허용된 Trusted Types 정책 목록을 정의합니다.

소스 목록 키워드

URL 외에도 CSP 지시어는 허용된 소스를 정의하기 위해 여러 키워드를 사용할 수 있습니다:

• 'self': 보호된 문서와 동일한 출처(스키마 및 도메인)의 콘텐츠를 허용합니다.
• 'unsafe-inline': 인라인 자바스크립트 및 CSS 사용을 허용합니다. CSP를 상당히 약화시키고 XSS 취약점을 다시 유발할 수 있으므로 극도의 주의를 기울여 사용해야 합니다. 가능하면 피하세요.
• 'unsafe-eval': eval() 및 Function()과 같은 동적 자바스크립트 평가 함수 사용을 허용합니다. 이 또한 CSP를 약화시키므로 주의해서 사용하세요. 템플릿 리터럴과 같은 대안을 고려하세요.
• 'unsafe-hashes': 특정 인라인 이벤트 핸들러의 SHA256, SHA384 또는 SHA512 해시를 허용 목록에 추가하여 허용합니다. 모든 인라인 이벤트 핸들러를 즉시 다시 작성하지 않고 CSP로 전환하는 데 유용합니다.
• 'none': 어떤 소스의 콘텐츠도 허용하지 않습니다.
• 'strict-dynamic': 신뢰할 수 있는 스크립트에 의해 로드된 스크립트가 정책에 따라 일반적으로 허용되지 않더라도 추가 스크립트를 로드할 수 있도록 허용합니다. 최신 자바스크립트 프레임워크에 유용합니다.
• 'report-sample': 위반 보고서에 위반 코드의 샘플을 포함하도록 브라우저에 지시합니다. CSP 문제를 디버깅하는 데 도움이 됩니다.
• data:: data: URL(예: 내장 이미지)에서 리소스 로드를 허용합니다. 주의해서 사용하세요.
• mediastream:: mediastream: URL(예: 웹캠 또는 마이크)에서 리소스 로드를 허용합니다.
• blob:: blob: URL(예: 동적으로 생성된 객체)에서 리소스 로드를 허용합니다.
• filesystem:: filesystem: URL(예: 로컬 파일 시스템 접근)에서 리소스 로드를 허용합니다.

CSP 구현: 실제 예제

CSP를 구현하는 두 가지 주요 방법이 있습니다:

1. HTTP 응답 헤더: 더 큰 유연성과 제어 기능을 제공하므로 권장되는 접근 방식입니다.
2. <meta> 태그: 더 간단한 접근 방식이지만, 제한 사항이 있습니다(예: frame-ancestors와 함께 사용할 수 없음).

예제 1: HTTP 응답 헤더

CSP 헤더를 설정하려면 웹 서버(예: Apache, Nginx, IIS)를 구성해야 합니다. 특정 구성은 서버 소프트웨어에 따라 다릅니다.

다음은 CSP 헤더의 예입니다:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

설명:

• default-src 'self': 기본적으로 동일한 출처의 리소스를 허용합니다.
• script-src 'self' https://example.com: 동일한 출처와 https://example.com에서 오는 자바스크립트를 허용합니다.
• style-src 'self' 'unsafe-inline': 동일한 출처의 CSS와 인라인 스타일을 허용합니다(주의해서 사용).
• img-src 'self' data:: 동일한 출처의 이미지와 데이터 URL을 허용합니다.
• report-uri /csp-report: 서버의 /csp-report 엔드포인트로 위반 보고서를 보냅니다.

예제 2: <meta> 태그

<meta> 태그를 사용하여 CSP 정책을 정의할 수도 있습니다:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:">

참고: <meta> 태그 접근 방식에는 제한이 있습니다. 예를 들어, 클릭재킹 공격 방지에 중요한 frame-ancestors 지시어를 정의하는 데 사용할 수 없습니다.

보고서 전용 모드의 CSP

CSP 정책을 시행하기 전에 보고서 전용 모드에서 테스트하는 것이 좋습니다. 이를 통해 리소스를 차단하지 않고 위반 사항을 모니터링할 수 있습니다.

보고서 전용 모드를 활성화하려면 Content-Security-Policy 대신 Content-Security-Policy-Report-Only 헤더를 사용하세요:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-uri /csp-report

보고서 전용 모드에서 브라우저는 지정된 URL로 위반 보고서를 보내지만 어떤 리소스도 차단하지 않습니다. 이를 통해 정책을 시행하기 전에 정책의 문제를 식별하고 수정할 수 있습니다.

보고 URI 엔드포인트 설정하기

report-uri (더 이상 사용되지 않음, `report-to` 사용) 지시어는 브라우저가 위반 보고서를 보내야 하는 URL을 지정합니다. 이러한 보고서를 수신하고 처리하기 위해 서버에 엔드포인트를 설정해야 합니다. 이 보고서들은 POST 요청의 본문에 JSON 데이터로 전송됩니다.

다음은 Node.js에서 CSP 보고서를 처리하는 방법에 대한 간단한 예입니다:

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;

app.use(bodyParser.json({ type: 'application/csp-report' }));

app.post('/csp-report', (req, res) => {
 console.log('CSP 위반 보고서:', JSON.stringify(req.body, null, 2));
 res.status(204).end(); // 204 No Content로 응답
});

app.listen(port, () => {
 console.log(`CSP 보고서 서버가 http://localhost:${port}에서 수신 대기 중입니다`);
});

이 코드는 /csp-report 엔드포인트에 대한 POST 요청을 수신하는 간단한 서버를 설정합니다. 보고서가 수신되면 콘솔에 보고서를 기록합니다. 실제 애플리케이션에서는 분석을 위해 이러한 보고서를 데이터베이스에 저장하는 것이 좋습니다.

`report-to`를 사용할 때는 `Report-To` HTTP 헤더도 구성해야 합니다. 이 헤더는 보고 엔드포인트와 그 속성을 정의합니다.

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}],"include_subdomains":true}

그런 다음 CSP 헤더에서 다음과 같이 사용합니다:

Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

CSP 모범 사례

CSP를 구현할 때 따라야 할 몇 가지 모범 사례는 다음과 같습니다:

• 엄격한 정책으로 시작하기: 제한적인 정책으로 시작하여 필요에 따라 점차 완화하십시오. 이렇게 하면 잠재적인 보안 취약점을 조기에 식별하고 해결하는 데 도움이 됩니다.
• 인라인 스크립트 및 스타일에 Nonce 또는 해시 사용: 인라인 스크립트나 스타일을 사용해야 하는 경우, nonce(암호학적으로 무작위 값)나 해시를 사용하여 특정 코드 블록을 허용 목록에 추가하십시오. 이는 'unsafe-inline'을 사용하는 것보다 더 안전합니다.
• 'unsafe-eval' 피하기: 'unsafe-eval' 지시어는 동적 자바스크립트 평가 함수의 사용을 허용하며, 이는 주요 보안 위험이 될 수 있습니다. 가능하면 이 지시어 사용을 피하십시오. 템플릿 리터럴이나 다른 대안을 고려하십시오.
• 모든 리소스에 HTTPS 사용: 중간자 공격을 방지하기 위해 모든 리소스가 HTTPS를 통해 로드되도록 하십시오. upgrade-insecure-requests 지시어를 사용하여 비보안 요청을 자동으로 업그레이드하십시오.
• 정책 모니터링 및 개선: 정기적으로 CSP 위반 보고서를 모니터링하고 필요에 따라 정책을 개선하십시오. 이를 통해 문제를 식별하고 해결하며 정책이 효과적으로 유지되도록 할 수 있습니다.
• CSP 생성기 사용 고려: 웹사이트의 요구 사항에 따라 CSP 정책을 생성하는 데 도움이 되는 여러 온라인 도구가 있습니다. 이러한 도구는 강력하고 효과적인 정책을 만드는 과정을 단순화할 수 있습니다.
• 철저한 테스트: CSP 정책을 시행하기 전에 보고서 전용 모드에서 철저히 테스트하여 웹사이트의 기능이 손상되지 않는지 확인하십시오.
• 프레임워크 또는 라이브러리 사용: 일부 웹 개발 프레임워크 및 라이브러리는 CSP에 대한 내장 지원을 제공합니다. 이러한 도구를 사용하면 CSP 정책을 구현하고 관리하는 과정을 단순화할 수 있습니다.
• 브라우저 호환성 인지: CSP는 대부분의 최신 브라우저에서 지원되지만 구형 브라우저에서는 일부 호환성 문제가 있을 수 있습니다. 다양한 브라우저에서 정책을 테스트하여 예상대로 작동하는지 확인하십시오.
• 팀 교육: 개발팀이 CSP의 중요성과 올바른 구현 방법을 이해하도록 하십시오. 이를 통해 개발 수명 주기 전반에 걸쳐 CSP가 올바르게 구현되고 유지되도록 할 수 있습니다.

CSP와 제3자 스크립트

CSP를 구현하는 데 있어 가장 큰 과제 중 하나는 제3자 스크립트를 다루는 것입니다. 많은 웹사이트가 분석, 광고 및 기타 기능을 위해 제3자 서비스에 의존합니다. 이러한 스크립트는 제대로 관리되지 않으면 보안 취약점을 유발할 수 있습니다.

CSP로 제3자 스크립트를 관리하기 위한 몇 가지 팁은 다음과 같습니다:

• 서브리소스 무결성(SRI) 사용: SRI를 사용하면 제3자 스크립트가 변조되지 않았는지 확인할 수 있습니다. 제3자 스크립트를 포함할 때 스크립트의 해시와 함께 integrity 속성을 포함하십시오. 그러면 브라우저는 스크립트를 실행하기 전에 해시와 일치하는지 확인합니다.
• 제3자 스크립트 로컬 호스팅: 가능하다면 제3자 스립트를 자체 서버에 로컬로 호스팅하십시오. 이렇게 하면 스크립트에 대한 더 많은 제어권을 갖고 손상될 위험을 줄일 수 있습니다.
• CSP를 지원하는 콘텐츠 전송 네트워크(CDN) 사용: 일부 CDN은 CSP에 대한 내장 지원을 제공합니다. 이는 제3자 스크립트에 대한 CSP 구현 및 관리 과정을 단순화할 수 있습니다.
• 제3자 스크립트의 권한 제한: CSP를 사용하여 제3자 스크립트의 권한을 제한하십시오. 예를 들어, 민감한 데이터에 접근하거나 승인되지 않은 도메인에 요청하는 것을 막을 수 있습니다.
• 제3자 스크립트 정기적 검토: 웹사이트에서 사용하는 제3자 스크립트를 정기적으로 검토하여 여전히 안전하고 신뢰할 수 있는지 확인하십시오.

고급 CSP 기법

기본적인 CSP 정책을 마련한 후에는 몇 가지 고급 기법을 탐색하여 웹사이트의 보안을 더욱 강화할 수 있습니다:

• 인라인 스크립트 및 스타일에 Nonce 사용: 앞서 언급했듯이, nonce는 특정 인라인 코드 블록을 허용 목록에 추가하는 데 사용할 수 있는 암호학적으로 무작위 값입니다. nonce를 사용하려면 각 요청에 대해 고유한 nonce를 생성하고 CSP 헤더와 인라인 코드 모두에 포함해야 합니다.
• 인라인 이벤트 핸들러에 해시 사용: 'unsafe-hashes' 지시어는 특정 인라인 이벤트 핸들러를 SHA256, SHA384 또는 SHA512 해시로 허용 목록에 추가할 수 있습니다. 이는 모든 인라인 이벤트 핸들러를 즉시 다시 작성하지 않고 CSP로 전환하는 데 유용할 수 있습니다.
• Trusted Types 사용: Trusted Types는 DOM 기반 XSS 취약점을 방지하는 데 도움이 되는 DOM API입니다. 특정 컨텍스트에서 안전하게 사용할 수 있음이 보장된 특수 유형의 객체를 생성할 수 있게 해줍니다.
• Feature Policy 사용: Feature Policy(현재는 Permissions Policy)를 사용하면 웹사이트에서 사용할 수 있는 브라우저 기능을 제어할 수 있습니다. 이는 특정 유형의 공격을 방지하고 웹사이트의 성능을 향상시키는 데 도움이 될 수 있습니다.
• 폴백(Fallback)과 함께 서브리소스 무결성(SRI) 사용: SRI를 폴백 메커니즘과 결합하십시오. SRI 검사가 실패하면(예: CDN 다운), 자체 서버에 호스팅된 리소스의 백업 복사본을 준비해 둡니다.
• 동적 CSP 생성: 사용자 세션, 역할 또는 기타 문맥 정보에 따라 서버 측에서 동적으로 CSP를 생성합니다.
• CSP와 웹소켓: 웹소켓을 사용할 때는 신뢰할 수 있는 웹소켓 엔드포인트에만 연결을 허용하도록 `connect-src` 지시어를 신중하게 구성하십시오.

CSP 구현에 대한 글로벌 고려 사항

글로벌 사용자를 대상으로 CSP를 구현할 때는 다음을 고려하십시오:

• CDN 위치: 콘텐츠 전송 네트워크(CDN)가 여러 지리적 위치에 서버를 보유하여 전 세계 사용자에게 빠르고 안정적인 콘텐츠를 제공하는지 확인하십시오. CDN이 CSP를 지원하고 필요한 헤더를 처리할 수 있는지 확인하십시오.
• 글로벌 규정: GDPR(유럽), CCPA(캘리포니아) 및 기타 지역 법률과 같은 데이터 프라이버시 규정을 인지하십시오. 특히 위반 보고서를 처리할 때 CSP 구현이 이러한 규정을 준수하는지 확인하십시오.
• 현지화: CSP가 현지화된 콘텐츠에 어떤 영향을 미칠 수 있는지 고려하십시오. 다른 언어 또는 지역에 대해 다른 스크립트나 스타일이 있는 경우, CSP 정책이 이러한 변형을 수용하는지 확인하십시오.
• 다국어 도메인 이름(IDN): 웹사이트가 IDN을 사용하는 경우, CSP 정책이 이러한 도메인을 올바르게 처리하는지 확인하십시오. 잠재적인 인코딩 문제나 브라우저 불일치에 유의하십시오.
• 교차 출처 리소스 공유(CORS): CSP는 CORS와 함께 작동합니다. 교차 출처 요청을 하는 경우, CORS 구성이 CSP 정책과 호환되는지 확인하십시오.
• 지역별 보안 표준: 일부 지역에는 특정 보안 표준이나 요구 사항이 있을 수 있습니다. 해당 지역의 사용자를 위해 CSP를 구현할 때 이러한 표준을 연구하고 준수하십시오.
• 문화적 고려 사항: 웹사이트가 사용되고 접근되는 방식에 대한 문화적 차이를 염두에 두십시오. 특정 지역이나 인구 통계에 특정한 잠재적 보안 위험을 해결하기 위해 CSP 구현을 조정하십시오.
• 접근성: CSP 구현이 웹사이트의 접근성에 부정적인 영향을 미치지 않도록 하십시오. 예를 들어, 스크린 리더나 기타 보조 기술에 필요한 스크립트나 스타일을 차단하지 마십시오.
• 지역별 테스트: 다양한 지리적 지역과 브라우저에서 CSP 구현을 철저히 테스트하여 잠재적인 문제를 식별하고 해결하십시오.

CSP 문제 해결

CSP를 구현하는 것은 때때로 어려울 수 있으며, 문제에 부딪힐 수 있습니다. 다음은 몇 가지 일반적인 문제와 해결 방법입니다:

• CSP 활성화 후 웹사이트 손상: 이는 종종 너무 제한적인 정책으로 인해 발생합니다. 브라우저의 개발자 도구를 사용하여 차단되는 리소스를 식별하고 그에 따라 정책을 조정하십시오.
• CSP 위반 보고서가 수신되지 않음: 서버 구성을 확인하여 report-uri(또는 `report-to`) 엔드포인트가 올바르게 구성되었는지, 그리고 서버가 POST 요청을 제대로 처리하고 있는지 확인하십시오. 또한, 브라우저가 실제로 보고서를 보내고 있는지 확인하십시오(개발자 도구를 사용하여 네트워크 트래픽을 확인할 수 있습니다).
• 인라인 스크립트 및 스타일 관련 어려움: 인라인 스크립트 및 스타일에 문제가 있는 경우, nonce나 해시를 사용하여 허용 목록에 추가하는 것을 고려하십시오. 또는 코드를 외부 파일로 옮기는 것을 시도해 보십시오.
• 제3자 스크립트 문제: SRI를 사용하여 제3자 스크립트의 무결성을 확인하십시오. 여전히 문제가 있는 경우, 스크립트를 로컬로 호스팅하거나 제3자 제공업체에 도움을 요청해 보십시오.
• 브라우저 호환성 문제: CSP는 대부분의 최신 브라우저에서 지원되지만 구형 브라우저에서는 일부 호환성 문제가 있을 수 있습니다. 다양한 브라우저에서 정책을 테스트하여 예상대로 작동하는지 확인하십시오.
• CSP 정책 충돌: 여러 CSP 정책(예: 다른 플러그인이나 확장 프로그램에서)을 사용하는 경우 서로 충돌할 수 있습니다. 플러그인이나 확장 프로그램을 비활성화하여 문제가 해결되는지 확인해 보십시오.

결론

콘텐츠 보안 정책은 웹사이트의 보안을 강화하고 다양한 위협으로부터 사용자를 보호하는 강력한 도구입니다. CSP를 올바르게 구현하고 모범 사례를 따르면 XSS 공격, 클릭재킹 및 기타 취약점의 위험을 크게 줄일 수 있습니다. CSP 구현은 복잡할 수 있지만, 보안 및 사용자 신뢰 측면에서 제공하는 이점은 충분히 그럴 만한 가치가 있습니다. 엄격한 정책으로 시작하고, 철저히 테스트하며, 정책이 효과적으로 유지되도록 지속적으로 모니터링하고 개선하는 것을 기억하십시오. 웹이 진화하고 새로운 위협이 등장함에 따라 CSP는 포괄적인 웹 보안 전략의 필수적인 부분으로 계속 남을 것입니다.